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REMARKS 



Claim amendments 

Applicant amends the claims to correct minor errors in grammar and to more clearly 
point out the subject matter of the invention. 

Applicant inserts commas at selected locations to clarify sentence structure. 

Applicant also amends the claims so that the word "comprising" occurs only once per 
claim. These amendments clarify the claims by more clearly demarcating the preamble from the 
body of the claim. 

Applicant corrects a claim dependency in claims 1 1-12 to conform to that in 
corresponding claims 4 and 5. 

Applicant amends claim 5 and 12 because, conceptually, it is not the data quality function 
itself that depends on data file sizes, but rather the output thereof. 

Applicant also removes repetitive phrases where necessary. 

The foregoing amendments are of a minor nature and introduce no new matter. Nor do 
the foregoing amendments have anything to do with overcoming the cited art. 

Applicant's disclosure 

Consider the bunny 202 shown in Applicant's FIG. 2. Somehow, data representing this 

bunny must be provided to the client. Otherwise, the client would not be able to draw it. This 
information that is needed to draw the bunny ultimately comes from the server. 

It turns out that there are two ways to draw the bunny 202. Some players may value high 
quality graphics. These players will cause their clients to draw an exquisitely detailed bunny. To 
draw such a bunny, the client must have a high-quality content file that provides it with 
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instructions to draw the exquisitely detailed bunny. The price of such quality is the need for 
greater hardware capability with better performance. 

Other players will be content with a less detailed bunny, particularly if it means better 
performance. These players will cause their clients to draw a lower quality bunny. To do so, 
these clients only need a low-quality content file for that bunny. 

Periodically, these content files are updated by the game's designers. These update 
content files must be transmitted to the various clients. Naturally, it would be wasteful to transfer 
high-quality content files to players who only use low-quality content files. The problem 
addressed by Applicant is how to efficiently manage the updating process so that different clients 
receive only those files that they need. 



Ideally, a game should simulate a seamless world in which players move freely from one 
part of the world to another, and in which players can freely play with other players. 

The reality, however, is that simulating a world, particularly a large one, typically 
requires the cooperation of many different servers. This introduces "seams" in what should be a 
seamless world. 

In a world created by the cooperation of many servers, all players at a particular location 
in this world are typically associated with whichever server manages that location. This causes 
difficulties. For example, in such a world, it can be more difficult to interact with players at other 
locations. Additionally, in such a world, there is a practical limit on how many players can be in 
a particular portion of that world. That limit depends on the hardware capabilities of the server 
responsible for managing that portion of the world. 

It is apparent that Poulin has absolutely nothing to do with delivering content files used 
by a client to draw objects such as bunnies and dragons. Instead, Poulin is directed to 

1 Poulin, U.S. Patent Publication 2003/0008712. 



Poulin' 
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overcoming practical limits associated with a server's ability to handle more state information 
than a certain number of players at the same time. 

State information, which is what data files 104, 106 contain, has been part of computer 
games since ancient times. For example, the very earliest text-based adventure games included 
state information to describe, for example, where the player was, or what he was carrying. 

Content information, on the other hand, describes what a player looks like. There was no 
need for content information until computer games began to include more detailed graphics. 

Thus, the distinction between state information in Poulin and the content information in 
Applicant's claims is a significant one rooted in history. State information and content 
information carry out different functions and raise different technical issues. 

This fundamental difference between the technical problems associated with managing 
state information as addressed by Poulirfs, disclosed system and Applicant's system for 
managing content information results in a flawed section 102 rejection. These flaws are 
discussed in more detail below. 

Section 102 rejection of claims 1, 8 and 15 

The Examiner appears to regard claim l's limitation of 



[0010] In another embodiment of the invention, there is provided a distributed system 
having a server operable for communicating with a plurality of clients. Each of the 
clients is positioned within a physical volume managed by the server. The server 
maintains a plurality of data sets having information about each one of clients. The 
server transmits to a first client the data sets associated with a predetermined number 
(fixed or dynamic) of the other clients that are interacting with the first client. The 
predetermined number of other clients is based upon a priority} 



"hosting for transmission a content update having a plurality of data files" 



as being taught by the following passage from Poulin: 



2 Poulin, paragraph 10. 
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While it is not altogether clear, Applicant assumes that the Examiner regards "data sets" in the 
above passage as being claim l's "data files," and that the Examiner regards any set of such data 
sets as being claim l's "content update." 

However, the "data sets" described in Poulin are not "content" as that term is understood 
by one of ordinary skill in the art. The "data sets" in Poulin contain "information about each one 
of the clients," 3 i.e., state information. They do not contain information needed to draw content, 
such as bunnies and dragons. Therefore, these datasets, which contain no "content" cannot 
possibly form a "content update" as required by claim 1 . 

Amended claim 1 also includes the limitation of 



The Examiner also appears to regard this claim limitation as taught by the following passage 
from Poulin: 

[0030] Now referring to FIG. 2. there is illustrated the server 14 (Server A) having a 
data set 100, the server 16 (Server B) having a data set 120, and the server 18 (Server 
N) having a data set 130. The data set 100 includes a plurality of data sets 102, 104, 
106 that include data corresponding to each client attached/linked/playing the system 
10. Other data sets, such as for objects, are also provided in the data set 100. The 
data set 102 includes the positional, status and event information/data for each 
particular client attached/linked to the server 14 (Server A) and for each object 
associated with server 14. The data set 104 includes a subset data of the positional, 
status and event information/data for each particular client attached/linked to the 
server 16 (Server B) and for objects associated with the server 16, while the data set 
106 includes a subset data of the positional, status and event information/data for 
each particular client attached/linked to the server 18 (Server N) and for objects 
associated with the server 18. As will be appreciated, additional servers may be used 
in the server platform 12, and for each server, a subset of data of the positional, status 
event information/data for those particular clients attached/linked to the server, and 
those objects associated with the server, will be included in the data set 100. 

Applicant concedes that a text search for the word "subset," which is used in claim 1, 
would have drawn attention to the foregoing passage. But a passage that uses the word "subset" 



identifying a subset of the plurality ofdatafilt 



high-quality data files 



3 Poulin, paragraph 10, lines 5-6. 

4 Poulin, paragraph 30. 
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even one, as is the case here, that uses the word "subset" three times in rapid succession, does 
not necessarily disclose a claim limitation that also happens to use the word "subset," 

The analysis of a patent claim requires more than simply hunting and pecking through a 
reference for words that may be common to those used in a claim. It requires carefully reading 
the passage to determine exactly what the passage teaches, and then understanding whether what 
the passage teaches is consistent with the claim. 

In the above passage, the word "subset" is associated with certain client data, such as 
position, status, and event information. Applicant therefore speculates that the Examiner regards 
position, status, and event information as somehow being claim l's "high-quality data files." 

As a threshold matter, it is unclear exactly what the Examiner regards as being "high 
quality" or "low quality." 

It is also unclear, however, why one client's position, status, or event information would 
be any more "high-quality" than another client's position, status, or event information. As best 
understood, in Poulin, a client's position, status, or event information is of the same "quality," 
whatever "quality" means, no matter who the client is or what the client's position, status or 
event information might be. 

The concept of "high-quality data files" is easily understood in the context of Applicant's 
disclosure. However, in the context of Poulin, the concept of a "high-quality data file" as distinct 
from a "low-quality data file" makes no sense at all. In Poulin, there appears to be no qualitative 
difference between data 102, 104, 106 stored in server A, data 112, 1 14, 116 stored in server B, 
and data 122, 124, 126 stored in server N. 

Independent claims 8 and 15 include limitations similar to those above. Accordingly, the 
section 102 rejection of those claims is improper for at least the same reasons given above. 
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The remaining claims are dependent on claims 1, 8, and 15, and are allowable for at least 
the same reasons. 

The remaining dependent claims are patentable for reasons beyond those discussed 
above. Representative ones of these dependent claims are discussed below. 

Section 102 rejection of claims 2 and 9 

Claim 2 recites the additional limitation of 

storing^ on a network storage device,, a content update having a plurality of data files. 
The Examiner suggests that Poulin teaches this claim limitation in the following passage: 

[0025] When there are relatively few clients participating in the game, generally only 
one server is needed to serve the clients. During game operation, there is no need for 
direct communication between clients. For 3D action games whereby clients interact 
with each other, each client needs positional, status and event information/data 
( referred to as client or player information, or as attributes) for every other client 
and/or object the client can see or interact with in the game grid/map. Such 
positional, status and event information includes, but is not limited to, type, 
physics/collision modeling, interac tion rules data, scoring, position, orientation, 
motion vector, animation, vehicle, call sign, or other client or object attributes 
necessary for the particular application. Typically, the server includes a data set or 
database of in formation that is maintained and updated as the clients interact within 
the game. With a small number of clients (with small number of clients on a single 
server or a few servers), the data transfer from the server to each client is 
manageable. However, as the number of clients increase, so does the amount of 
information/data to be transferred to each client. In order to handle larger numbers of 
clients, prior art systems limited the data transfer to a particular client by only 
transmitting information/data on a certain number of clients or objects closest to the 
particular client. When only one server is utilized due to a small number of clients, the 
server maintains the positional, status and event information/data database for all 
clients on the server, and transfers updates to each client when required. When the 
n umber of clients increases, the number of servers allocated also increases; however, 
each server only maintains a database for the particular clients attached/linked to the 
5 

server. 

There are two kinds of information one might want to know about a person: what the 
person looks like, and what the person is doing. The first type of information is encoded in the 



5 Poulin, paragraph 25. 
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person's genes and is expected to be more or less constant during that person's existence. The 
second type of information which is sometimes called "state information," varies from moment- 
to-moment as the person interacts with the world. 

In the same way, there are two kinds of information about a player in an on-line game: 
what the player looks like, and what the player is doing. The first type of information is found in 
the content files that are referred to in the claims. The second type of information, i.e. state 
information, is what paragraph 25 refers to. 

Paragraph 25 of Poulin describes updating state information that changes for each player 
as the game is played. Examples of such information include position, status, and event 
information. This does not amount to a "content update." This information describes what a 
player is doing at any moment. It has nothing to do with how a player appears on the screen. 

For example, if a player is a bunny 202, the position, status, and event information 
referred to in Poulin' s paragraph 25 might describe whether the bunny is on a mountain or in a 
valley or perhaps the bunny's level of hunger, or the extent of the bunny's injuries. But it does 
not describe what the bunny will look like on a display. 

The distinction is a fundamental one, similar to the distinction between information 
encoded in a person's genes and information provided by a handheld GPS system. The 
information referred to in Poulin is the latter type. Poulin never refers to content data. 

Claim 9 recites limitations similar to claim 2 and is patentable for at least the same 
reasons. 

Section 102 rejection of claims 6 and 13 

Claim 6 recites the additional limitation of 

removing the high-quality data files from, the content update 
The Examiner suggests that this limitation is also taught by Poulirfs paragraph 25. 
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As discussed above in connection with claim 2, paragraph 25 describes updating clients 
by transmitting data files from the server to the client. As best understood, the Poulin server 
maintains a set of data files. When an update is necessary, certain ones of these data files are 
retrieved and sent to a client. There is no discussion of actually removing these data files from 
the set of data files, so that they are no longer part of that set. 

Section 102 rejection of claim 3, 10, and 16 

Claim 3 recites the additional limitation of 

using a data quality junction to identify a subset oj the plurality of data files contained 
in the content update as high -quality datajiles 

The Examiner states that Poulin teaches this limitation in the following: 

[0010] In another embodiment of the invention, there is provided a distributed system 
having a server operable jor communicating with a plurality of clients. Each ojthe 
clients is positioned within a physical volume managed by the server. The server 
maintains a plurality of data sets having information about each one of clients. The 
server transmits to a jirst client the data sets associated with a predetermined number 
(fixed or dynamic) ojthe other clients that are interacting with the first client. The 
predetermined number of other clients is based upon a priority. 

Based on the Examiner's earlier remarks, the "data files" of claim 3 are believed to be 
regarded as corresponding to the "data sets having information about each of the clients." It is 
unclear, however, what text in Poulin's paragraph 10 might possibly correspond to using a "data 
quality function." 

Claims 10 and 16 include imitations similar to claim 3 and is patentable for the same 



Section 102 rejection of claim 5 and 12 

Claim 5 recites the additional limitation that the data quality function yield a data quality 

that is a function of the sizes of data files. 

The Examiner states that Poulin teaches this limitation in the following passage: 



Poulin, paragraph 10. 
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[0046] With continued reference to FIG. 3, let us assume that the servers 204 each 
have a specific volume associated with each server, and that the volumes and servers 
are identified as volumes A-I. As will be appreciated, the volumes A-I may be different 
sizes and shapes. Each volume A-I represents a geographic region within the game, 
and a specific number of clients/objects are associated with each volume (positioned 
within that region of the game). Directing attention to volume E, let us assume that 
new clients are entering the game in volume E, or clients are congregating in volume 
E(i.e., the battle is converging in region E,for some reason). As the number of clients 
in volume E increases, the server load increases. At some point, the sen>er load will 
increase and processing will suffer thus degrading the game. At this point, in prior art 
systems, no additional clients would be allowed to enter volume E. 

Applicant is unable to determine exactly what relevance this passage has to claim 5 
beyond the fact that a text search for the word "sizes" would have drawn attention to the above 



The mere fact that a passage of text includes a word used in a claim does not mean that 
the passage anticipates the claim limitation. Patent examination requires more than merely 
finding a word from a claim in a passage of text in a reference. It requires understanding of the 



Even a cursory reading of the above passage reveals that the "sizes" referred to are sizes 
of particular volumes of geographic regions and have nothing to do with sizes of data files. 
Accordingly, there is no basis whatsoever for asserting that Poulin 's statement 



could possibly amount to a disclosure of using a data quality function that depends on sizes of 



Claim 12 includes imitations similar to claim 5 and is patentable for the same reasons. 



Section 102 rejection of claims 7 and 14 

Claim 7 recites the additional limitation that the client connection request include 



1 Poulin, paragraph 46. 

8 Poulin, paragraph 46, line 5. 



paragraph. 



passage. 
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"a bit value indicating high-quality files should be transferred" 
The Examiner suggests that Poulin teaches this claim limitation in the following text: 

[0048] Upon a dynamic distribution or allocation, any clients (and objects) 
positioned in a new volume served by a different server are transferred to the new 
server. Upon dynamic distribution of the volumes, the iden tity of those client(s) whose 
volumes have changed (i.e., the client is now in a new volume served by a different 
server) is determined. Wlien determined, the sending server sends a client transfer 
request to the receiving server. The request includes all client information. When the 
transfer request is received, the new server adds the client to the client index hash and 
sends an acknowledgment. Upon receipt of the acknowledgment, the old server 
instructs the client's application program to make a new connection to the new server, 
and also transmits a handshake to the new server. The client's application then closes 
the connection to the old ser\>er? 

However, the foregoing text merely describes what happens when a player moves from 
the domain of one server to another. 

Applicant notes that a search for the word "request," which is also used in the claim, 
would have drawn attention to the cited text. Applicant therefore assumes that the Examiner 
regards "transfer request" as being claim 7's "connection request." But Poulin' s "transfer 
request" is a request from one server to another. It is not a "client connection request." 

Claim 7 also requires that the connection request have a bit value indicating whether 
high-quality files should be transferred. 

But according to the cited text, this request "includes all client information." 10 Hence, 
there is no distinction between high-quality files and low-quality files. The Poulin "transfer 
request" is intended to transfer all client data from one server to another. 

Summary 

Now pending in this application are claims 1-20, of which claims 1,8, and 15 are 
independent. No fees are believed to be due in connection with the filing of this response. 



9 Poulin, paragraph 48. 

10 Poulin, paragraph 48, line 8. 
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